Managing hidden security features in user equipment

ABSTRACT

A device determines whether a PTT application is authenticated to access a first API and a second API, and prevents the PTT application from accessing the first and second APIs when the PTT application is not authenticated. The device permits the PTT application to access the first and second APIs when the PTT application is authenticated, and modifies, via the first API, a timer that dictates when the device checks for traffic received from a network. The device establishes, via the second API, a data connection with the network, and determines, based on the data connection, a QoS framework for the network. The device utilizes the PTT application and the timer to establish a PTT session with another device via the network, and prioritizes, based on the QoS framework, PTT traffic provided in the PTT session with the other device.

BACKGROUND

A push-to-talk (PTT) service provides direct one-to-one and/orone-to-many audio communication. PTT may include a mechanism thatprovides instantaneous communication between parties, and that utilizesa button to switch user equipment (UE) from a voice transmission mode toa voice reception mode. The operation of UEs in this manner may besimilar to how walkie talkies operate. A PTT service may switch a UEfrom a full duplex mode, where both parties may hear each othersimultaneously, to a half duplex mode, where a single party may speak atone time. Multiple parties to a conversation may also be included.Availabilities of parties may be checked before a call with the help ofa presence function.

In the Third Generation Partnership Project (3GPP), the fourthgeneration (4G) cellular network includes an evolved packet system(EPS). The EPS may include a radio access network (e.g., referred to asa long term evolution (LTE) network), a wireless core network (e.g.,referred to as an evolved packet core (EPC) network), an Internetprotocol (IP) multimedia subsystem (IMS) network, and a packet datanetwork (PDN). The LTE network is often called an evolved universalterrestrial radio access network (E-UTRAN). The EPC network is an all-IPpacket-switched core network that supports high-speed wireless andwireline broadband access technologies. The EPC network allows UEs toaccess various services by connecting to the LTE network, an evolvedhigh rate packet data (eHRPD) radio access network (RAN), and/or awireless local area network (WLAN) RAN. The IMS network may include anarchitectural framework or network (e.g., a telecommunications network)for delivering IP multimedia services. The PDN may include acommunications network that is based on packet switching.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an overview of an example implementationdescribed herein;

FIG. 2 is a diagram of an example environment in which systems and/ormethods described herein may be implemented;

FIG. 3 is a diagram of example components of a device that maycorrespond to one or more of the devices of the environment depicted inFIG. 2;

FIG. 4 is a flow chart of an example process for granting or denyingaccess to exposed application programming interfaces (APIs);

FIGS. 5A-5C are diagrams of an example relating to the example processshown in FIG. 4;

FIG. 6 is a flow chart of an example process for establishing andconducting a PTT session with another UE based on exposed APIs; and

FIGS. 7A-7H are diagrams of an example relating to the example processshown in FIG. 6.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements.

Current 4G PTT applications use a public Internet connection with noquality of service (QoS) for PTT services. Without QoS, a user's PTTexperience may degrade when a network or a UE is busy and PTT traffic isqueued up behind other traffic (e.g., email, video, Internet, etc.traffic). The user experience may be exemplified in what is called a“push to hear” delay, which measures how quickly a user hears a beepafter pushing the PTT button and how quickly the user's voice reaches acalled party. Current 4G PTT applications have push to hear delays ofapproximately 1.5 to 2 seconds, which creates a poor user experience.

FIG. 1 is a diagram of an overview of an example implementation 100described herein. As shown, a user may be associated with a UE connectedto an EPS that includes a RAN, an EPC network, an IMS network, and aPDN. The UE may include a PTT application that enables the user toestablish and conduct a PTT call (or session) via the EPS. In order toenhance the PTT application to improve the PTT session, a manufacturerof the UE may expose one or more hidden or unexposed APIs. For example,the UE manufacturer may expose an IMS PDN API and a DiscontinuousReceive (DRX) cycle API, as shown in FIG. 1. The IMS PDN API may enablethe UE to establish data routes to the IMS network and the PDN. The DRXcycle API may enable the UE to modify a DRX cycle timer that dictateswhen the UE checks a network for traffic.

However, since the exposed APIs may affect battery life of the UE andmay be susceptible to security threats, the UE may include a securityapplication that restricts access to the exposed APIs, as further shownin FIG. 1. The security application may provide secure access to the IMSPDN API and the DRX cycle API by the PTT application, and may preventunauthorized applications from accessing the IMS PDN API and the DRXcycle API.

For example, the security application may include authenticationcredentials (e.g., a signature, a security token, a security key, or thelike) that may be utilized to authenticate applications attempting toaccess the IMS PDN API and/or the DRX cycle API. The securityapplication may request that a particular application attempting toaccess the IMS PDN API and/or the DRX cycle API provide a credential. Ifthe credential provided by the particular application matches thecredential of the security application, the security application mayauthenticate the particular application for accessing the IMS PDN APIand/or the DRX cycle API. When the PTT application is installed in theUE, the PTT application may be provided with a credential that matchesthe credential of the security application. Therefore, the securityapplication may authenticate the PTT application for accessing the IMSPDN API and/or the DRX cycle API, as shown in FIG. 1. The securityapplication may provide, to an operating system of the UE, a messageindicating that the PTT application is authenticated for accessing theIMS PDN API and/or the DRX cycle API.

As further shown in FIG. 1, the PTT application may request access tothe IMS PDN API, and the IMS PDN API may check with the operating systemto determine whether the PTT application is authenticated. Since the PTTapplication is authenticated, the IMS PDN API may grant the PTTapplication access to the IMS PDN API. The PTT may utilize the IMS PDNAPI to establish a data connection (e.g., set up data routes) with thePDN over the IMS network. Unlike the public Internet, the IMS networkmay permit the UE to utilize quality of service (QoS) with respect toPTT sessions. In some implementations, the QoS may include prioritizingPTT traffic over other types of traffic, such as, for example, email,video, and Internet traffic. The QoS may improve a call setup time forestablishing a PTT session, and may improve a latency time associatedwith the PTT session.

As further shown in FIG. 1, the PTT application may request access tothe DRX cycle API, and the DRX cycle API may check with the operatingsystem to determine whether the PTT application is authenticated. Sincethe PTT application is authenticated, the DRX cycle API may grant thePTT application access to the DRX cycle API. The PTT application mayaccess the DRX cycle API in order to modify the DRX cycle timer providedin the DRX cycle API. In some implementations, the PTT application maydecrease the DRX cycle timer so that the UE checks the EPS for traffic(e.g., PTT traffic) more frequently. This may enable the UE to morequickly receive PTT traffic from the EPS, such as an incoming PTT call,which may result in shorter call setup times (e.g., relative to publicInternet-based PTT).

Such PTT enhancements may permit prioritization of PTT traffic overother types of traffic, such as email, video, Internet, etc. traffic.This may provide improved PTT call setup time and/or latency time overcurrent 4G PTT implementations, which may improve the PTT userexperience. For example, the PTT enhancements may provide push to heardelays of approximately less than one second.

Implementations of the security application are described herein withrespect to a PTT application and to particular APIs exposed for thepurpose of enhancing the PTT application. However, the securityapplication may be utilized to provide secure access to one or moreexposed APIs of the UE, other than the particular exposed APIs describedherein (e.g., the IMS PDN API and the DRX cycle API). For example, thesecurity application may be utilized to grant or deny the PTTapplication, and/or one or more other applications of the UE, access toany exposed API of the UE. Furthermore, although the PTT application isdescribed herein in terms of PTT voice calls, the PTT application mayalternatively or additionally be utilized for PTT video calls.

FIG. 2 is a diagram of an example environment 200 in which systemsand/or methods described herein may be implemented. As illustrated,environment 200 may include a UE 210 and an EPS 215 that includes a LTEnetwork 220, an EPC network 230, an IMS network 240, and a PDN 250. LTEnetwork 220 may include an eNodeB (eNB) 222. EPC network 230 may includea mobility management entity (MME) 232, a serving gateway (SGW) 234, apolicy and charging rules function (PCRF) 236, and a PDN gateway (PGW)238. IMS network 240 may include a home subscriber server (HSS) 242 anda proxy call session control function (P-CSCF) 244. Devices/networks ofenvironment 200 may connect via wired connections, wireless connections,or a combination of wired and wireless connections.

As further shown in FIG. 2, eNB 222 may connect with MME 232 over aS1-MME interface, and may connect with SGW 234 over a S1-U interface.MME 232 may connect with SGW 234 over a S11 interface, and may connectwith HSS 242 over a Sha interface. SGW 234 may connect with PGW 238 overa S5 interface. PCRF 236 may connect with PGW 238 over a Gx interface.PGW 238 may connect with PDN 250 over a SGi interface, and may connectwith P-CSCF 244. Other connections, not shown in FIG. 2, may also beutilized by EPS 215. For example, multiple MMEs 232 may connect with oneanother over S10 interfaces.

UE 210 may include a device that is capable of communicating over LTEnetwork 220, EPC network 230, and/or IMS network 240. In someimplementations, UE 210 may include a radiotelephone; a PCS terminalthat may combine, for example, a cellular radiotelephone with dataprocessing and data communications capabilities; a smart phone; a PDAthat can include a radiotelephone, a pager, Internet/intranet access,etc.; a laptop computer; a tablet computer; a desktop computer; aworkstation computer; a personal computer; a landline telephone; oranother type of computation and communication device.

EPS 215 may include is a core network architecture of the 3GPP LTEwireless communication standard. EPS 215 may include LTE network 220,EPC network 230, IMS network 240, and PDN 250.

LTE network 220 may include a communications network that connects users(e.g., UE 210) to a service provider network. In some implementations,LTE network 220 may include a wireless local area network (WLAN) oranother type of access network (e.g., an E-UTRAN or an eHRPD network).In some implementations, LTE network 220 may include a radio accessnetwork capable of providing a particular data rate, a particularlatency, packet optimization, a particular capacity and coverage, etc.

eNB 222 may include one or more computation and communication devices,such as a base station, that receive traffic from MME 232 and/or SGW 234and transmit that traffic to UE 210. eNB 222 may also include one ormore devices that receive traffic from UE 210 and transmit that trafficto MME 232 and/or SGW 234 or to other UEs 210. eNB 222 may combine thefunctionalities of a base station and a radio network controller (RNC)in 2G or 3G radio access networks.

EPC network 230 may include an IP packet-switched core network thatsupports high-speed wireless and wireline broadband access technologies.In some implementations, EPC network 230 may provide packet-switchedvoice services (e.g., which are traditionally circuit-switched) usingIMS network 240 and PDN 250.

MME 232 may include one or more computation and communication devicesthat may be responsible for idle mode tracking and paging procedures(e.g., including retransmissions) for UE 210. MME 232 may be involved ina bearer activation/deactivation process (e.g., for UE 210) and maychoose a SGW for UE 210 at an initial attach and at a time of intra-LTEhandover. In some implementations, MME 232 may authenticate UE 210.Non-access stratum (NAS) signaling may terminate at MME 232, and MME 232may generate and allocate temporary identities to UEs 210. MME 232 maycheck authorization of UE 210 to utilize LTE network 220 and may enforceroaming restrictions for UE 210. MME 232 may be a termination point inEPC network 230 for ciphering/integrity protection for NAS signaling andmay handle security key management. MME 232 may provide a control planefunction for mobility between LTE network 220 and other access networkswith a S3 interface terminating at MME 232.

SGW 234 may include one or more devices that route and forward user datapackets, may act as a mobility anchor for a user plane during inter-eNBhandovers, and may act as an anchor for mobility between LTE and other3GPP technologies. For idle state UEs 210, SGW 234 may terminate adownlink data path and may trigger paging when downlink data arrives forUE 210. SGW 234 may manage and store contexts associated with UE 210(e.g., parameters of an IP bearer service, network internal routinginformation, etc.). In some implementations, SGW 234 may include one ormore traffic transfer devices (or network devices), such as a gateway, arouter, a switch, a firewall, a network interface card (NIC), a hub, abridge, a proxy server, an optical add-drop multiplexer (OADM), or someother type of device that processes and/or transfers traffic.

PCRF 236 may include one or more computation and communication devicesthat provide policy control decision and flow based charging controlfunctionalities. PCRF 236 may provide network control regarding servicedata flow detection, gating, QoS and flow based charging, etc. In someimplementations, PCRF 236 may determine how a certain service data flowshall be treated, and may ensure that user plane traffic mapping andtreatment is in accordance with a user's subscription profile.

PGW 238 may include one or more devices that provide connectivity of UE210 to external packet data networks by being a traffic exit/entry pointfor UE 210. UE 210 may simultaneously connect to more than one PGW 238for accessing multiple PDNs 250. PGW 238 may perform policy enforcement,packet filtering for each user, charging support, lawful intercept, andpacket screening. PGW 238 may also act as an anchor for mobility between3GPP and non-3GPP technologies. In some implementations, PGW 238 mayinclude one or more traffic transfer devices (or network devices), suchas a gateway, a router, a switch, a firewall, a NIC, a hub, a bridge, aproxy server, an OADM, or some other type of device that processesand/or transfers traffic.

IMS network 240 may include an architectural framework or network (e.g.,a telecommunications network) for delivering IP multimedia services. Insome implementations, IMS network 240 may include a standardizedreference architecture that provides session control, a connectioncontrol and an applications services framework, and user and servicesdata.

HSS 242 may include one or more computation and communication devicesthat provide a master user database that supports devices of IMS network240 that handle calls. HSS 242 may contain subscription-relatedinformation (e.g., user profiles), may perform authentication andauthorization of a user, and may provide information about a user'slocation and IP information.

P-CSCF 244 may include one or more computation and communication devicesthat function as a proxy server for UE 210, where SIP signaling trafficto and from UE 210 may go through P-CSCF 244. In some implementations,P-CSCF 244 may validate and then forward requests from UE 210, and mayprocess and forward responses to UE 210.

PDN 250 may include one or more data communications networks that arebased on packet switching, as opposed to circuit switching that is usedin public telephone networks. In some implementations, PDN 250 may becapable of communicating with UE 210 over IMS network 240.

The number of devices and/or networks shown in FIG. 2 is provided as anexample. In practice, there may be additional devices and/or networks,fewer devices and/or networks, different devices and/or networks, ordifferently arranged devices and/or networks than those shown in FIG. 2.Furthermore, two or more devices shown in FIG. 2 may be implementedwithin a single device, or a single device shown in FIG. 2 may beimplemented as multiple, distributed devices. Additionally, one or moreof the devices of environment 200 may perform one or more functionsdescribed as being performed by another one or more devices ofenvironment 200.

FIG. 3 is a diagram of example components of a device 300 that maycorrespond to one or more of the devices of environment 200. In someimplementations, one or more of the devices of environment 200 mayinclude one or more devices 300 or one or more components of device 300.As shown in FIG. 3, device 300 may include a bus 310, a processor 320, amemory 330, an input component 340, an output component 350, and acommunication interface 360.

Bus 310 may include a path that permits communication among thecomponents of device 300. Processor 320 may include a processor (e.g., acentral processing unit, a graphics processing unit, an acceleratedprocessing unit, etc.), a microprocessor, and/or any processingcomponent (e.g., a field-programmable gate array (FPGA), anapplication-specific integrated circuit (ASIC), etc.) that interpretsand/or executes instructions, and/or that is designed to implement aparticular function. In some implementations, processor 320 may includemultiple processor cores for parallel computing. Memory 330 may includea random access memory (RAM), a read only memory (ROM), and/or anothertype of dynamic or static storage component (e.g., a flash, magnetic, oroptical memory) that stores information and/or instructions for use byprocessor 320.

Input component 340 may include a component that permits a user to inputinformation to device 300 (e.g., a touch screen display, a keyboard, akeypad, a mouse, a button, a switch, etc.). Output component 350 mayinclude a component that outputs information from device 300 (e.g., adisplay, a speaker, one or more light-emitting diodes (LEDs), etc.).

Communication interface 360 may include a transceiver-like component,such as a transceiver and/or a separate receiver and transmitter, whichenables device 300 to communicate with other devices, such as via awired connection, a wireless connection, or a combination of wired andwireless connections. For example, communication interface 360 mayinclude an Ethernet interface, an optical interface, a coaxialinterface, an infrared interface, a radio frequency (RF) interface, auniversal serial bus (USB) interface, a high-definition multimediainterface (HDMI), or the like.

Device 300 may perform various operations described herein. Device 300may perform these operations in response to processor 320 executingsoftware instructions included in a computer-readable medium, such asmemory 330. A computer-readable medium may be defined as anon-transitory memory device. A memory device may include memory spacewithin a single physical storage device or memory space spread acrossmultiple physical storage devices.

Software instructions may be read into memory 330 from anothercomputer-readable medium or from another device via communicationinterface 360. When executed, software instructions stored in memory 330may cause processor 320 to perform one or more processes describedherein. Additionally, or alternatively, hardwired circuitry may be usedin place of or in combination with software instructions to perform oneor more processes described herein. Thus, implementations describedherein are not limited to any specific combination of hardware circuitryand software.

The number of components shown in FIG. 3 is provided as an example. Inpractice, device 300 may include additional components, fewercomponents, different components, or differently arranged componentsthan those shown in FIG. 3. Additionally, or alternatively, one or morecomponents of device 300 may perform one or more functions described asbeing performed by another one or more components of device 300.

FIG. 4 is a flow chart of an example process 400 for granting or denyingaccess to exposed APIs. In some implementations, one or more processblocks of FIG. 4 may be performed by UE 210. In some implementations,one or more process blocks of FIG. 4 may be performed by another deviceor a group of devices separate from or including UE 210.

As shown in FIG. 4, process 400 may include exposing an IMS PDN API anda DRX cycle API to a PTT application (block 410). For example, UE 210may include a PTT application that enables UE 210 to establish andconduct PTT sessions with other UEs 210. In some implementations, UE 210may include an IMS PDN API that enables UE 210 to establish a dataconnection with PDN 250 over IMS network 240, as opposed to over thepublic Internet. For example, the IMS PDN API may enable the PTTapplication to make a data connection with PDN 250 over IMS network 240.In some implementations, UE 210 may include several hidden or unexposedAPIs that may not be viewed or altered by applications provided in UE210. However, the IMS PDN API may be exposed by UE 210 so that the PTTapplication may utilize the IMS PDN API to establish a data connectionwith PDN 250 over IMS network 240.

In some implementations, UE 210 may include a DRX cycle API thatcontrols a DRX cycle timer associated with UE 210. The DRX cycle timermay include a timer that dictates when UE 210 checks a network fortraffic (e.g., UE 210 may check a network for traffic after expirationof the DRX cycle timer). In some implementations, the DRX cycle API maybe exposed by UE 210 so that the PTT application may modify the DRXcycle timer. For example, UE 210 may decrease the DRX cycle timer sothat UE 210 checks EPS 215 for traffic (e.g., PTT traffic) morefrequently. This may enable UE 210 to more quickly receive PTT trafficfrom EPS 215.

As further shown in FIG. 4, process 400 may include receiving, by asecurity application, a credential from the PTT application (block 420).For example, UE 210 may include a security application that providessecure access to exposed APIs in UE 210. In some implementations, thesecurity application may provide secure access to the IMS PDN API andthe DRX cycle API by the PTT application. In some implementations, thesecurity application may prevent unauthorized applications fromaccessing the IMS PDN API and the DRX cycle API.

For example, the security application may include authenticationcredentials (e.g., a certificate, a signature, an authentication key, asecurity token, etc.) that may be utilized to authenticate applicationsattempting to access the IMS PDN API and/or the DRX cycle API. Thesecurity application may request that a particular applicationattempting to access the IMS PDN API and/or the DRX cycle API provideauthentication credentials.

In some implementations, the PTT application may be installed in UE 210by a manufacturer of UE 210, may be installed by a network serviceprovider, or may be downloaded and installed in UE 210 by a user of UE210. When the PTT application is installed in UE 210, the PTTapplication may be provided with authentication credentials (e.g., asignature), and may provide the authentication credentials to thesecurity application. The security application may receive theauthentication credentials (e.g., the signature).

As further shown in FIG. 4, process 400 may include determine whetherthe credential received from the PTT application matches a credentialassociated with the security application (block 430). For example, thesecurity application may determine whether the authenticationcredentials received from the PTT application match the authenticationcredentials of the security application. In some implementations, theauthentication credentials of the security application may include afirst signature associated with a first certificate, a first privatesigning key, and/or a first public verification key. The authenticationcredentials of the PTT application may include a second signatureassociated with a second certificate, a second private signing key,and/or a second public verification key. In such implementations, thesecurity application may determine whether the first signature matchesthe second signature. For example, the security application maydetermine whether the first certificate matches the second certificate,whether the first private signing key matches the second private signingkey, and/or whether the first public verification key matches the secondpublic verification key.

As further shown in FIG. 4, if the credential received from the PTTapplication matches the credential associated with the securityapplication (block 430—YES), process 400 may include authenticating thePTT application for accessing the IMS PDN API and the DRX cycle API(block 440). For example, if the authentication credentials provided bythe PTT application match the authentication credentials of the securityapplication, the security application may authenticate the PTTapplication for accessing the IMS PDN API and/or the DRX cycle API. Insome implementations, when the PTT application is installed in UE 210,the PTT application may be provided with authentication credentials thatmatch the authentication credentials of the security application.Therefore, the security application may authenticate the PTT applicationfor accessing the IMS PDN API and/or the DRX cycle API.

When the PTT application is authenticated for access to the IMS PDN APIand the DRX cycle API, the PTT application may utilize and/or modify theIMS PDN API and the DRX cycle API. In some implementations, the PTTapplication may utilize the IMS PDN API to establish a data connection(e.g., set up data routes) with PDN 250 over IMS network 240. The PTTapplication may utilize the data connection over IMS network 240 toimplement a QoS framework for PTT traffic associated with the PTTapplication.

In some implementations, when the PTT application is installed in UE 210or when UE 210 receives a tracking area update (TAU) (e.g., a TAU may beperformed periodically or when UE 210 moves to another set of cells ortracking area) from EPS 215, the PTT application may access the DRXcycle API in order to modify the DRX cycle API. For example, the PTTapplication may modify the DRX cycle timer provided in the DRX cycleAPI. In some implementations, the PTT application may decrease the DRXcycle timer so that UE 210 checks EPS 215 for traffic (e.g., PTTtraffic) more frequently (e.g., every so many milliseconds, seconds,minutes, etc.). This may enable UE 210 to more quickly receive PTTtraffic from EPS 215, such as an incoming PTT call, which may result inshorter call setup times (e.g., relative to public Internet-based PTT).

In some implementations, the PTT application may restore the DRX cycletimer to a configurable default value based on particular conditions.For example, the PTT application may restore the DRX cycle timer to thedefault value when UE 210 is connected to an access network other thanLTE network 220 (e.g., when UE 210 connects to a wireless LAN (WLAN)).In such an example, the PTT application may modify the DRX cycle timeragain when UE 210 reconnects to LTE network 220.

As further shown in FIG. 4, if the credential received from the PTTapplication does not match the credential associated with the securityapplication (block 430—NO), process 400 may include not authenticatingthe PTT application for accessing the IMS PDN API and the DRX cycle API(block 440). For example, if the authentication credentials provided bythe PTT application fail to match the authentication credentials of thesecurity application, the security application may not authenticate thePTT application for accessing the IMS PDN API and/or the DRX cycle APIand may generate an error (e.g., a security exception error). In someimplementations, another application of UE 210 may maliciously or notmaliciously attempt to access the IMS PDN API and/or the DRX cycle API.The other application may not be provided with a credential that matchesthe credential of the security application. Prior to attempting toaccess the IMS PDN API and/or the DRX cycle API, the other applicationmay provide the non-matching credential to the security application, andthe security application may not authenticate the other application foraccessing the IMS PDN API and/or the DRX cycle API.

In some implementations, the security application may notify theoperating system of UE 210 of the result of the authentications. Forexample, the security application may inform the operating system thatthe PTT application is authenticated for accessing the IMS PDN API andthe DRX cycle API. In another example, the security application mayinform the operating system that the other application is notauthenticated for accessing the IMS PDN API and the DRX cycle API.

Although FIG. 4 shows example blocks of process 400, in someimplementations, process 400 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 4. Additionally, or alternatively, two or more of theblocks of process 400 may be performed in parallel.

FIGS. 5A-5C are diagrams of an example 500 relating to example process400 shown in FIG. 4. In example 500, assume that UE 210 includesunexposed APIs 505 that are hidden from a user of UE 210 and/orapplications executing on UE 210, as shown in FIG. 5A. Unexposed APIs505 may include an IMS PDN API 510 that enables UE 210 to establish adata connection with PDN 250 over IMS network 240, and a DRX cycle API515 that controls a DRX cycle timer associated with UE 210. As furthershown in FIG. 5A, IMS PDN API 510 and DRX cycle API 515 may be exposedto a PTT application 520 that enables UE 210 to establish and conductPTT sessions with other UEs 210. IMS PDN API 510 and DRX cycle API 515may be exposed to PTT application 520 so that PTT application 520 mayutilize and/or modify IMS PDN API 510 and/or DRX cycle API 515.

As shown in FIG. 5B, UE 210 may include a security application 525 thatdetermines whether an application is authenticated for accessing IMS PDNAPI 510 and/or DRX cycle API 515. Security application 525 may include acredential 530 that is utilized to authenticate applications attemptingto access IMS PDN API 510 and/or DRX cycle API 515. As further shown inFIG. 5B, PTT application 520 may provide a credential 535 to securityapplication 525. Assume that security application 525 determines thatcredential 535 provided by PTT application 520 matches credential 530 ofsecurity application 525. Accordingly, security application 525 maydetermine that PTT application 520 is authenticated for accessing IMSPDN API 510 and/or DRX cycle API 515, as indicated by reference number540, and may provide this information to an operating system of UE 210.

As further shown in FIG. 5B, PTT application 520 may provide an accessrequest 545 to IMS PDN API 510, and IMS PDN API 510 may check 550, basedon access request 545, with the operating system to determine whetherPTT application 520 is authenticated for accessing IMS PDN API 510.Since PTT application 520 is authenticated, PTT application 520 may begranted access to IMS PDN API 510, as indicated by reference number 555.PTT application 520 may provide an access request 560 to DRX cycle API515, and DRX cycle API 515 may check 565, based on access request 560,with the operating system to determine whether PTT application 520 isauthenticated for accessing DRX cycle API 515. Since PTT application 520is authenticated, PTT application 520 may be granted access to DRX cycleAPI 515, as indicated by reference number 570.

As shown in FIG. 5C, another application of UE 210 may provide acredential 575 to security application 525. Assume that securityapplication 525 determines that credential 575 provided by the otherapplication does not match credential 530 of security application 525.Accordingly, security application 525 may determine that the otherapplication is not authenticated for accessing IMS PDN API 510 and/orDRX cycle API 515, as indicated by reference number 580, and may providethis information to the operating system.

As further shown in FIG. 5C, the other application may provide an accessrequest 585 to IMS PDN API 510 and/or DRX cycle API 515. IMS PDN API 510and/or DRX cycle API 515 may check 590, based on access request 585,with the operating system to determine whether the other application isauthenticated for accessing IMS PDN API 510 and/or DRX cycle API 515.Since the other application is not authenticated, the other applicationmay be denied access to IMS PDN API 510 and/or DRX cycle API 515, asindicated by reference number 595.

As indicated above, FIGS. 5A-5C are provided merely as an example. Otherexamples are possible and may differ from what was described with regardto FIGS. 5A-5C.

FIG. 6 is a flow chart of an example process 600 for establishing andconducting a PTT session with another UE based on exposed APIs. In someimplementations, one or more process blocks of FIG. 6 may be performedby UE 210. In some implementations, one or more process blocks of FIG. 6may be performed by another device or a group of devices separate fromor including UE 210.

As shown in FIG. 6, process 600 may include modifying a DRX cycle timerwith a PTT application and via a DRX cycle API (block 610). For example,the PTT application of UE 210 may access the DRX cycle API, and maymodify the DRX cycle timer provided in the DRX cycle API. In someimplementations, the security application may provide secure access tothe DRX cycle API by the PTT application. In some implementations, thePTT application may decrease the DRX cycle timer so that UE 210 checksEPS 215 for traffic (e.g., PTT traffic) more frequently. This may enableUE 210 to more quickly receive PTT traffic from EPS 215, such as anincoming PTT call, which may result in shorter call setup times (e.g.,relative public Internet-based PTT).

As further shown in FIG. 6, process 600 may include establishing, via anIMS PDN API and the PTT application, data routes with a network (block620). For example, the PTT application of UE 210 may access the IMS PDNAPI, and may utilize the IMS PDN API. In some implementations, thesecurity application may provide secure access to the IMS PDN API by thePTT application. In some implementations, the PTT application mayutilize the IMS PDN API to establish a data connection (e.g., set updata routes) with PDN 250 over IMS network 240. Unlike the publicInternet, IMS network 240 may permit UE 210 to utilize QoS with respectto PTT sessions. The QoS may improve a call setup time for establishinga PTT session, and may improve a latency time associated with the PTTsession.

As further shown in FIG. 6, process 600 may include establishing a QoSframework with the network for prioritizing PTT traffic (block 630). Forexample, UE 210 may connect to PDN 250 over IMS network 240 and via LTEnetwork 220 and EPC network 230. In some implementations, the PTTapplication of UE 210 may establish a QoS framework with EPS 215 (e.g.,with IMS network 240) that prioritizes PTT traffic associated with thePTT application. For example, the PTT application may prioritize PTTtraffic over best effort traffic (e.g., email traffic, video traffic,Internet traffic, etc.), as the PTT traffic traverses IMS network 240and PDN 250.

In some implementations, since the IMS PDN API may permit the PTTapplication to establish a data connection with PDN 250 over IMS network240, the PTT application may utilize the data connection over IMSnetwork 240 to implement a QoS framework for PTT traffic associated withthe PTT application. In some implementations, QoS bearers may be definedin IMS network 240 and may be set up statically when UE 210 registerswith IMS network 240. In some implementations, the QoS bearers may beset up dynamically when UE 210 utilizes the PTT application to make aPTT call.

In some implementations, the PTT traffic may be prioritized afterguaranteed bit rate (GBR) conversational audio (e.g., voice-over-IP(VoIP) traffic); before non-GBR variable bit rate video traffic; beforenon-GBR standard video telephony, video streaming, and general besteffort traffic; and before non-GBR machine-to-machine (M2M) traffic. Byprioritizing the PTT traffic over the non-GBR traffic, the PTTapplication may reduce latency times associated with PTT sessions.

As further shown in FIG. 6, process 600 may include utilizing the PTTapplication and the modified DRX cycle timer to establish a PTT sessionwith a UE (block 640). For example, UE 210 may utilize the modified DRXcycle timer to check EPS 215 for traffic, such as a PTT call fromanother UE 210. When UE 210 receives the PTT call from the other UE 210,and UE 210 may execute the PTT application based on receiving the PTTcall. Based on the PTT call, the PTT application may display informationindicating that the other UE 210 is trying to establish a PTT sessionwith UE 210. If the user accepts the PTT call, a PTT session may beestablished between UE 210 and the other UE 210. If the user does notaccept the PTT call, a PTT session may not be established between UE 210and the other UE 210.

In some implementations, the user may instruct UE 210 to execute the PTTapplication, and the user may utilize the PTT application to establish aPTT session with the other UE 210. In some implementations, the PTTapplication may display a list of available PTT contacts associated withthe user, and the user may select a PTT contact associated with theother UE 210 from the list. When the user selects the PTT contact, thePTT application may cause UE 210 to generate a PTT call destined for theother UE 210. In some implementations, UE 210 may provide the PTT callto the other UE 210 via EPS 215. If the PTT contact accepts the PTTcall, a PTT session may be established between UE 210 and the other UE210. If the PTT contact does not accept the PTT call, a PTT session maynot be established between UE 210 and the other UE 210.

As further shown in FIG. 6, process 600 may include prioritizing the PTTtraffic during the PTT session based on the QoS framework (block 650).For example, during the PTT session, UE 210 may prioritize the PTTtraffic over best effort traffic based on the QoS framework establishedwith EPS 215. In some implementations, during the PTT session, the otherUE 210 may also prioritize the PTT traffic over any best effort trafficassociated with the other UE 210, based on the QoS framework establishedwith EPS 215. In some implementations, the PTT traffic, in the PTTsession with the other UE 210, may be prioritized before non-GBRtraffic, such as, for example, variable bit rate video traffic, standardvideo telephony traffic, video streaming traffic, general best efforttraffic, and M2M traffic. By prioritizing the PTT traffic over thenon-GBR traffic, the PTT application may reduce latency times associatedwith PTT session with the other UE 210.

In some implementations, the combination of the reduced DRX cycle timer,the QoS framework for PTT traffic, and other enhancements (e.g., framebundling of PTT traffic) may provide improved PTT call setup time and/orlatency time over current 4G PTT implementations, which may improve thePTT user experience for the users of UE 210 and the other UE 210. Forexample, the combination may enable the user of UE 210 to experiencepush to hear delays of approximately less than one second during the PTTsession with the other UE 210. In some implementations, the combinationmay enable the user of the other UE 210 to experience push to heardelays of approximately less than one second during the PTT session withUE 210.

As further shown in FIG. 6, process 600 may include determining whetherthe PTT application is uninstalled (block 660). For example, thesecurity application may determine whether the PTT application isuninstalled (or removed) from UE 210. In some implementations, the userof UE 210 may utilize an uninstall function of UE 210 to request thatthe PTT application be uninstalled. The uninstall function, whenimplemented by the user, may perform operations to uninstall the PTTapplication from UE 210. In some implementations, the operating systemof UE 210 may notify the security application about any applicationsthat are uninstalled from UE 210, including the PTT application.

As further shown in FIG. 6, if the PTT application is not uninstalled(block 660—NO), process 600 may include ending the PTT session with theUE (block 670). For example, if the security application determines thatthe PTT application is not uninstalled, UE 210 may continue to use thePTT application. In some implementations, the user of UE 210 mayeventually end the PTT session with the other UE 210 by selecting amechanism (e.g., an end call button, icon, link, etc.) displayed by thePTT application during the PTT session. In some implementations, whenthe user of UE 210 selects the end call mechanism, UE 210 may terminatethe PTT session with the other UE 210, and may display informationassociated with the PTT application to the user. In someimplementations, UE 210 may display other information (e.g., dataassociated with best effort traffic, a home page, etc.) to the user whenthe PTT session is terminated. In some implementations, the user of theother UE 210 may end the PTT session with UE 210.

As further shown in FIG. 6, if the PTT application is uninstalled (block660—YES), process 600 may include utilizing the IMS PDN API to removethe data routes with the network (block 680). For example, if thesecurity application determines that the PTT application is uninstalledfrom UE 210, or if the PTT application is turned off or disabled (e.g.,by the user), the security application may utilize the IMS PDN API toremove any data routes set up by the PTT application via the IMS PDNAPI. In some implementations, the security application may utilize theIMS PDN API to remove any data connections (e.g., data routes)established with PDN 250 over IMS network 240. In some implementations,if the PTT application is turned on or enabled (e.g., by the user), thePTT application may utilize the IMS PDN API to establish another dataconnection (e.g., set up data routes) with PDN 250 over IMS network 240.

As further shown in FIG. 6, if the PTT application is uninstalled (block660—YES), process 600 may include utilizing the DRX cycle API to resetthe DRX cycle timer to a default value (block 690). For example, if thesecurity application determines that the PTT application is uninstalledfrom UE 210, the security application may utilize the DRX cycle API toreset the DRX cycle timer to a default value. In some implementations,the security application may reset the DRX cycle timer to a configurabledefault value that may reduce battery usage in UE 210. For example, thedefault value of the DRX cycle timer may include a value that causes UE210 to check EPS 215 for traffic less frequently, which may conservebattery usage in UE 210.

In some implementations, if the PTT application is removed oruninstalled from UE 210, or if the PTT application is turned off ordisabled (e.g., by the user), the security application may reset the DRXcycle timer to a configurable default value that may reduce batteryusage in UE 210. For example, the default value of the DRX cycle timermay include a value that causes UE 210 to check EPS 215 for traffic lessfrequently, which may conserve battery usage in UE 210. In someimplementations, the security application may read a default DRX valuethat is being broadcasted by EPS 215, and may use the default DRX valueto change the DRX cycle timer of UE 210 to the default value. This mayreset the DRX cycle timer of UE 210 to a default value which EPS 215wants devices to use (e.g., when using the default value). In someimplementations, if the PTT application is turned on or enabled (e.g.,by the user), the PTT application may decrease the DRX cycle timer sothat UE 210 checks EPS 215 for traffic (e.g., PTT traffic) morefrequently (e.g., every so many milliseconds, seconds, minutes, etc.).

Although FIG. 6 shows example blocks of process 600, in someimplementations, process 600 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 6. Additionally, or alternatively, two or more of theblocks of process 600 may be performed in parallel.

FIGS. 7A-7H are diagrams of an example 700 relating to example process600 shown in FIG. 6. As shown in FIG. 7A, assume that a user isassociated with UE 210 (e.g., a smart phone 210), and that smart phone210 includes IMS PDN API 510, DRX cycle API 515, and PTT application520. As further shown in FIG. 7A, PTT application 520 may access DRXcycle API 515, and may instruct DRX cycle API 515 to modify the DRXcycle timer. DRX cycle API 515 may modify the DRX cycle timer based theinstruction, and UE 210 may utilize modified DRX cycle timer 705 tocheck EPS 215 for traffic. Assume that modified DRX cycle timer 705causes smart phone 210 to check EPS 215 for information more frequentlythan before the DRX cycle timer was modified. PTT application 520 mayaccess IMS PDN API 510, and may instruct IMS PDN API 510 to establishdata routes in EPS 215. IMS PDN API 510 may establish data routes withIMS network 240 and PDN 250 based on the instruction, as indicated byreference number 710. As further shown in FIG. 7A, PTT application 520may determine, with EPS 215, a QoS framework 715 that prioritizes PTTtraffic.

As shown in FIG. 7B, while the user is creating an email message, smartphone 210 may check EPS 215 for information (e.g., received calls,traffic, etc.) based on a modified DRX cycle timer 705, as indicated byreference number 720. As further shown in FIG. 7B, a coworker of theuser may be associated with a tablet computer 210, and may utilizetablet computer 210 to access a PTT application provided in tabletcomputer 210. Assume that the coworker utilizes the PTT application togenerate a request 725 for a PTT session with the user and smart phone210. Tablet computer 210 may provide request 725 for the PTT session toEPS 215, and EPS 215 may forward request 725 toward smart phone 210utilizing the QoS framework.

When request 725 is received by smart phone 210, smart phone 210 mayexecute a PTT application provided in smart phone 210 and may stopdisplaying email message 715. The PTT application may cause smart phone210 to display information associated with request 725, such as thecoworker's name, the coworker's picture, a mechanism to accept or denyrequest 725, etc. Assume that the user utilizes the displayedinformation to accept request 725, and establish a PTT session withtablet computer 210 and the coworker, as indicated by reference number730 in FIG. 7C. When the PTT session is established, the PTT applicationmay cause smart phone 210 to display a user interface 735 that includesa picture of coworker, a PTT button, and an end call button. As furthershown in FIG. 7C, the PTT application of smart phone 210 may prioritizePTT traffic associated with the PTT session, as indicated by referencenumber 740.

As shown in FIG. 7D, assume that the user selects 745 the PTT button andbegins talking to smart phone 210, as indicated by reference number 750.The user's spoken voice may be provided by smart phone 210 to tabletcomputer 210 (e.g., via EPS 215), and may be heard by the coworker viatablet computer 210, as indicated by reference number 755. As furthershown in FIG. 7D, a delay time between when the user speaks and when thecoworker hears the user's voice may be approximately less than onesecond, as indicated by reference number 760.

As shown in FIG. 7E, assume that the coworker selects 765 the PTT buttonand begins talking to tablet computer 210, as indicated by referencenumber 770. The coworker's spoken voice may be provided by tabletcomputer 210 to smart phone 210 (e.g., via EPS 215), and may be heard bythe user via smart phone 210, as indicated by reference number 775. Asfurther shown in FIG. 7E, a delay time between when the coworker speaksand when the user hears the coworker's voice may be approximately lessthan one second, as indicated by reference number 780.

Either the user or the coworker may end the PTT session by selecting theend call button. When the end call button is selected, smart phone 210and tablet computer 210 may end the PTT session, as indicated byreference number 785 in FIG. 7F. As further shown, after the PTT sessionends, smart phone 210 may resume displaying email message 715 to theuser, and tablet computer 210 may display a home page or some otherinformation to the coworker.

Now assume that the user utilizes an uninstall function of smart phone210 to request that PTT application 520 be uninstalled from smart phone210. When the uninstall function is invoked, smart phone 210 may displaya user interface 590 to the user, as shown in FIG. 7G. User interface790 may ask whether the user wants to uninstall PTT application 520.Assume that the user selects a Yes button of user interface 590 toindicate that the user wants to uninstall PTT application 520. When theuser selects the Yes button, smart phone 210 may uninstall PTTapplication 520 from smart phone 210.

After smart phone 210 uninstalls PTT application 520, securityapplication 525 may receive (e.g., from the operating system of smartphone 210) a notification indicating that PTT application 520 has beenuninstalled from smart phone 210. Based on the notification, securityapplication 525 may instruct DRX cycle API 515 to reset the DRX cycletimer, as indicated by reference number 795 in FIG. 7H, and DRX cycleAPI 514 may reset the DRX cycle timer to a default value. Based on thenotification, security application 525 may instruct IMS PDN API 510 toremove data routes established in EPS 215, as indicated by referencenumber 797 in FIG. 7H, and IMS PDN API 510 may remove any data routesestablished with IMS network 240 and PDN 250.

As indicated above, FIGS. 7A-7H are provided merely as an example. Otherexamples are possible and may differ from what was described with regardto FIGS. 7A-7H.

To the extent the aforementioned implementations collect, store, oremploy personal information provided by individuals, it should beunderstood that such information shall be used in accordance with allapplicable laws concerning protection of personal information. Storageand use of personal information may be in an appropriately secure mannerreflective of the type of information, for example, through variousencryption and anonymization techniques for particularly sensitiveinformation.

The foregoing disclosure provides illustration and description, but isnot intended to be exhaustive or to limit the implementations to theprecise form disclosed. Modifications and variations are possible inlight of the above disclosure or may be acquired from practice of theimplementations.

A component is intended to be broadly construed as hardware, firmware,or a combination of hardware and software.

It will be apparent that systems and/or methods, as described herein,may be implemented in many different forms of software, firmware, andhardware in the implementations illustrated in the figures. The actualsoftware code or specialized control hardware used to implement thesesystems and/or methods is not limiting of the implementations. Thus, theoperation and behavior of the systems and/or methods were describedwithout reference to the specific software code—it being understood thatsoftware and control hardware can be designed to implement the systemsand/or methods based on the description herein.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of possible implementations. In fact,many of these features may be combined in ways not specifically recitedin the claims and/or disclosed in the specification. Although eachdependent claim listed below may directly depend on only one claim, thedisclosure of possible implementations includes each dependent claim incombination with every other claim in the claim set.

No element, act, or instruction used herein should be construed ascritical or essential unless explicitly described as such. Also, as usedherein, the articles “a” and “an” are intended to include one or moreitems, and may be used interchangeably with “one or more.” Furthermore,as used herein, the term “set” is intended to include one or more items,and may be used interchangeably with “one or more.” Where only one itemis intended, the term “one” or similar language is used. Further, thephrase “based on” is intended to mean “based, at least in part, on”unless explicitly stated otherwise.

What is claimed is:
 1. A method, comprising: determining, by a device, whether a push-to-talk (PTT) application, provided in the device, is authenticated to access a first application programming interface (API) and a second API; preventing, by the device, the PTT application from accessing the first API and the second API when the PTT application is not authenticated; permitting, by the device, the PTT application to access the first API and the second API when the PTT application is authenticated; modifying, by the device and via the first API when the PTT application is permitted to access the first API, a timer associated with the device, the timer dictating when the device checks for traffic received from a network; establishing, by the device and via the second API when the PTT application is permitted to access the second API, a data connection with the network; determining, by the device and based on the data connection, a quality of service (QoS) framework for the network, the QoS framework assigning priorities to different types of traffic associated with the device; utilizing, by the device, the PTT application and the timer to establish a PTT session with another device via the network; and prioritizing, by the device and based on the QoS framework, PTT traffic provided in the PTT session with the other device.
 2. The method claim 1, where determining whether the PTT application is authenticated further comprises: determining whether an authentication credential, associated with the PTT application, matches an authentication credential associated with a security application of the device; authenticating the PTT application to access the first API and the second API when the authentication credential, associated the PTT application, matches the authentication credential associated with the security application; and failing to authenticate the PTT application to access the first API and the second API when the authentication credential, associated the PTT application, fails to match the authentication credential associated with the security application.
 3. The method of claim 1, where modifying the timer further comprises: accessing the first API with the PTT application; and utilizing the PTT application to instruct the first API to modify the timer.
 4. The method of claim 1, where establishing the data connection with the network further comprises: accessing the second API with the PTT application; and utilizing the PTT application to instruct the second API to establish the data connection with the network.
 5. The method of claim 1, further comprising: determining that the PTT application is removed from the device; restoring, via the first API, the timer to a default value when the PTT application is removed from the device; and removing, via the second API, the data connection with the network when the PTT application is removed from the device.
 6. The method of claim 1, where the network includes an Internet protocol (IP) multimedia subsystem (IMS) network and a packet data network (PDN), and the method further comprises: accessing the second API with the PTT application; and utilizing the second API to establish the data connection with the IMS network and the PDN.
 7. The method of claim 1, where modifying the timer further comprises: decreasing the timer from a first value to a second value, the first value of the timer causing the device to check for traffic received from the network at a first frequency, the second value of the timer causing the device to check for traffic received from the network at a second frequency, and the second frequency being greater than the first frequency.
 8. A device, comprising: a memory to store a push-to-talk (PTT) application; and one or more processors to: determine whether the PTT application is authenticated to access a first application programming interface (API) and a second API, the first API and the second API being exposed to the PTT application, permit the PTT application to access the first API and the second API when the PTT application is authenticated, modify, via the first API when the PTT application is permitted to access the first API, a timer associated with the device, the timer dictating when the device checks for traffic received from a network, establish, via the second API when the PTT application is permitted to access the second API, a data connection with the network, determine, based on the data connection, a quality of service (QoS) framework for the network, the QoS framework assigning priorities to different types of traffic associated with the device, utilize the PTT application and the timer to establish a PTT session with another device via the network, prioritize, based on the QoS framework, PTT traffic provided in the PTT session with the other device, and utilize the PTT application to terminate the PTT session with the other device.
 9. The device claim 8, where, when determining whether the PTT application is authenticated, the one or more processors are further to: determine whether a credential associated with the PTT application matches a credential associated with a security application of the device, and authenticate the PTT application to access the first API and the second API when the credential associated the PTT application matches the credential associated with the security application.
 10. The device of claim 8, where, when modifying the timer, the one or more processors are further to: access the first API with the PTT application, and utilize the PTT application to instruct the first API to modify the timer.
 11. The device of claim 8, where, when establishing the data connection with the network, the one or more processors are further to: access the second API with the PTT application, and utilize the PTT application to instruct the second API to establish the data connection with the network.
 12. The device of claim 8, where the one or more processors are further to: determine that the PTT application is removed from the device, restore, via the first API, the timer to a default value when the PTT application is removed from the device, and terminate, via the second API, the data connection with the network when the PTT application is removed from the device.
 13. The device of claim 8, where the network includes an Internet protocol (IP) multimedia subsystem (IMS) network and a packet data network (PDN), and the one or more processors are further to: access the second API with the PTT application, and utilize the second API to establish the data connection with the IMS network and the PDN.
 14. The device of claim 8, where, when modifying the timer, the one or more processors are further to: decrease the timer from a first value to a second value, the first value of the timer causing the device to check for traffic received from the network at a first frequency, the second value of the timer causing the device to check for traffic received from the network at a second frequency, and the second frequency being greater than the first frequency.
 15. A non-transitory computer-readable medium for storing instructions, the instructions comprising: one or more instructions that, when executed by one or more processors of a device, cause the one or more processors to: cause a security application to: determine whether a push-to-talk (PTT) application is authenticated to access a first application programming interface (API) and a second API, and permit the PTT application to access the first API and the second API when the PTT application is authenticated; and cause the PTT application to: modify, via the first API when the PTT application is permitted to access the first API, a timer associated with the device, the timer dictating when the device checks for traffic received from a network, establish, via the second API when the PTT application is permitted to access the second API, a data connection with the network, determine, based on the data connection, a quality of service (QoS) framework for the network, the QoS framework assigning priorities to different types of traffic associated with the device, utilize the timer to establish a PTT session with another device via the network, and prioritize, based on the QoS framework, PTT traffic provided in the PTT session with the other device.
 16. The computer-readable medium of claim 15, where the instructions further comprise: one or more instructions that, when executed by the one or more processors, cause the one or more processors to: cause the security application to: determine whether a credential associated with the PTT application matches a credential associated with the security application, and authenticate the PTT application to access the first API and second API when the credential associated the PTT application matches the credential associated with the security application.
 17. The computer-readable medium of claim 15, where, when modifying the timer, the instructions further comprise: one or more instructions that, when executed by the one or more processors, cause the one or more processors to: cause the PTT application to: access the first API, and instruct the first API to modify the timer.
 18. The computer-readable medium of claim 15, where, when establishing the data connection with the network, the instructions further comprise: one or more instructions that, when executed by the one or more processors, cause the one or more processors to: cause the PTT application to: access the second API, and instruct the second API to establish the data connection with the network.
 19. The computer-readable medium of claim 15, where the network includes an Internet protocol (IP) multimedia subsystem (IMS) network and a packet data network (PDN), and the instructions further comprise: one or more instructions that, when executed by the one or more processors, cause the one or more processors to: cause the PTT application to: access the second API, and instruct the second API to establish the data connection with the IMS network and the PDN.
 20. The computer-readable medium of claim 19, where the instructions further comprise: one or more instructions that, when executed by the one or more processors, cause the one or more processors to: cause the security application to: determine that the PTT application is uninstalled from the device, restore, via the first API, the timer to a default value when the PTT application is uninstalled from the device, and terminate, via the second API, the data connection with the network when the PTT application is uninstalled from the device. 